Fix #463 - broken inter-window update messages #464
Closed
+564
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses a couple of issues:
and addresses a related issue (related to dealing with WindowIds - the solution falls out of the solution for the above):
This patch adds atracking data structure:
root-id:WindowId
:Arc<Window>
which is populated on window creation and cleared on destruction, which makes it possible to accessWindow.request_redraw()
to force a redraw. It is guarded by a read-write lock (but written to only during window creation and destruction).So, a ViewId that wants its window-id looks up its root view's id, and looks up the WindowId associated with that root.
We extend
WindowId
with methods to get the window bounds on screen with and without decorations and similar - these methods could be added toViewId
instead, but it seems more intuitive that you ask a window id for the window's bounds the same way you ask a view id for the view's bounds - that seems like what users will expect.Given the usage patterns (the mapping will only be locked for writing when a window is being created or destroyed, and will not be read-locked except in the case of forcing a repaint or looking up window coordinates), it is not touched in the critical path of rendering - unless the application and destroying many windows at the same time on different threads, I would not expect the read-write lock to be contended at all in practice (famous last words, I know).
A thread-local for the mapping, as is done in
update.rs
might work (or look like it works), but we would be assuming no platform floem will ever support uses different event threads for different windows' event loops. I know of two that do - BeOS and Java AWT (with its stack of event threads to allow modal dialogs that work when their parent is disabled or blocked, which was a source of "interesting" deadlocks).If there was some path that I missed that would let a
ViewId
reach down to theWindowHandle
that owns it without doing this sort of tracking, I would love to know about it -PaintCx
has this information, but it is the only thing that does, and theViewId
has no access to it.